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1  OVERVIEW 


This  report  addresses  the  feasibility  of  and  require¬ 
ments  for  interfacing  two  powerful  software  engineering 
tools  -  POD  (Performance  Oriented  Design)  developed  by  BGS 
Systems  Inc.  and  HOS  developed  by  High  Order  Software,  Inc. 
of  Cambridge,  MA. 

PCD  is  a  software  engineering  tool  for  the  life  cycle  man¬ 
agement  of  system  performance.  It  is  a  tool  which  provides 
a  structured  machine  readable  format  (the  System  Description 
File  or  SDF)  for  representing  a  system's  hardware  architec¬ 
ture,  software  structure  and  external  load  demand.  Based  on 
this  representation,  PCD  provides  a  vehicle  to  calculate 
system  performance  values  such  as  response  time,  throughput 
and  device  utilization. 


Hic^er  Order  Software  (H3S) "  is  a  methodology  for  defining 
systems  in  a  hardware  and  language  independent  manner.  It 
consists  of  a  specification  language  AXES,  which  provides 
mechanisms  for  defining  functions,  control  structures,  and 
data  types,  a  User  System  Evaluation  and  Integration  Tool 
(USE. IT),  which  is  a  family  of  tools  for  defining  systems 
using  the  AXES  language,  an  Analyzer  for  analyzing  the  logi¬ 
cal  correctness  of  systems  defined  in  AXES,  and  a  family  of 
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RATs  (Resource  Allocation  Tools) ,  which  translate  descrip¬ 
tions  from  the  AXES  specification  language  into  target  lan¬ 
guages  such  as  Fortran  and  (potentially)  POD.  The  AXES  lan¬ 
guage  consists  of  both  a  specification  language  (for  de¬ 
scribing  the  application  or  other  system  to  be  built)  and  a 
metalanguage  for  describing  new  data  types  and  their  associ- 
-  ated  axioms.  The  latter  is  a  facility  for  extending  the 
AXES  language  to  incorporate  new  types  of  information. 

In  considering  the  feasibility  of  and  requirements  for  in¬ 
terfacing  POD  and  HOS,  HDS  is  assessed  in  terms  of  its  abil¬ 
ity  to  describe  the  required  POD  input  specifications.  In 
addition,  consideration  is  given  to  possible  HOS  extensions 
to  support  POD,  and  an  approach  for  interfacing  these  tools 
is  suggested. 

The  HOS  report  is  organized  as  follows:  Page  one  of  the  ac¬ 
companying  HOS  report  contains  the  introduction;  pages  3  and 
4  contain  a  summary  of  PCD  facilities;  pages  5  and  6  give  an 
overview  of  HOS  and  USE. IT;  pages  7  thru  35  describe  the  HOS 
-  PCD  interface,  which  is  the  meat  of  the  report;  page  37 
has  a  list  of  references  to  HDS  papers  (plus  a  reference  to 
the  POD  reference  manual) ;  Appendix  A  (which  is  separately 
numbered)  consists  of  pages  177  to  188  of  the  POD  reference 
manual. 

The  report  contains  a  description  of  parts  of  the  POD  SIS’ 
language  in  terms  of  AXES  axioms  and  an  example  of  how  some 


information  in  a  typical  PCD  SDF  oould  be  expressed  using 
AXES  constructs.  It  is,  thus,  useful  and  illustrative  of 
how  a  canplete  specification  of  PCD  information  in  the  HOS 
environment  oould  be  done. 

The  rationale  for  this  task  was  to  enable  users  to  present  a 
unified  description  of  a  system  in  the  HOS  requirement  spe¬ 
cification  language  (AXES)  in  such  a  way  that  sufficient  in¬ 
formation  would  be  embodied  in  such  a  description  so  that 
both  a  higher  level  language  (e.g.  Fortran)  program  and  a 
PCX)  model  oould  be  generated  from  that  description.  In  ord¬ 
er  to  do  this,  two  things  must  be  done. 

1.  Conventions  must  be  established  so  that  the  necessary 
performance  related  information  can  be  embedded  in  a 
system  specification  written  in  the  AXES  language. 

2.  Hie  PCD  SDF  language  must  be  defined  to  HOS  so  that 
an  actual  translation  can  be  done. 

Once  this  is  done  a  translator  (called  a  RAT  in  HOS  termi¬ 
nology)  can  be  built  that  uses  information  embedded  in  a  HOS 
description  of  a  system  and  information  about  the  informa¬ 
tion  layout  used  by  PCD  to  generate  a  PCD  model.  HDS  also 
has  a  facility  to  do  limited  consistency  checking  of  this 
performance  related  information. 

The  HOS  report  presents  two  main  pieces  of  new  information: 
1.  A  definition  of  a  subset  of  the  PCD  SOP  syntax  in  the 
AXES  metalanguage. 
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An  example  of  how  sample  pieces  of  a  PCD  SDF  model  of 
a  systen  could  be  expressed  in  the  AXES  language. 

The  AXES  metalanguage  provides  a  facility  for  extending  the 
AXES  syntax  by  introducing  new  primitives  that  support  PCD 
concepts  such  as  workload  and  device  definitions.  These  are 
not  normally  part  erf  a  requirements  or  HLL  specification  for 
a  systen.  The  extension  syntax  is  defined  in  the  AXES  meta¬ 
language  as  axioms  and  data  types.  Values  can  then  be  asso¬ 
ciated  with  these  new  data  types  as  part  of  a  system  re¬ 
quirements  specification.  As  an  example  of  hew  the 
definition  of  PCD  constructs  can  be  produced,  the  HOS  report 
provides  AXES  metalanguage  definitions  of  four  PCD  syntax 
constructs t 

1.  device  type  (pp.7-12) 

2.  file  catalog  (pp. 12-13) 

3.  workload  (pp. 14-16) 

4.  workload  type  (p.17) 

The  definitions  are  typical  of  what  would  be  required  for  a 
oomplete  definition  of  the  PCD  input  language. 

The  HOS  report  also  specifies  a  set  of  conventions  for  how 
information  needed  by  PCD  can  be  expressed  in  the  AXES  lan¬ 
guage  and  how  these  specifications  correspond  to  the  infor¬ 
mation  in  a  PCD  SDF.  The  report  gives  examples  of  how  six 
such  types  of  information  (needed  to  build  a  POD  model  of  a 
systen)  can  be  incorporated  in  an  AXES  language  specifica¬ 
tion.  The  cc  'ots  illustrated  are: 
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1.  loop  statement  (pp.14,  18-20,  and  22) 

2.  case  statement  (pp. 20-21  and  23-24) 

3.  file  catalog  (pp. 25-26) 

4.  device  description  (pp.25  and  27-29) 

5.  device  classes  (pp.25  and  29) 

6.  workload  specification  (p.30) 

7.  module  description  (pp.25  and  31-34) 

Both  the  HOS  and  POD  constructs  for  describing  each  of  these 
types  of  information  are  illustrated  so  that  the  correspon¬ 
dence  between  the  two  ways  of  describing  them  can  be  com¬ 
pared. 

An  important  issue  is  that  POD  uses  a  probabilistic  descrip¬ 
tion  of  the  differents  paths  through  a  program  (choices  in  a 
TEST/tZASE  statement)  while  a  conventional  programming  lan¬ 
guage  uses  a  specification  of  the  conditions  that  will  cause 
one  or  another  path  to  be  taken.  These  probabilities  must 
be  incorporated  into  the  HOS  AXES  requirement  specification 
in  order  for  a  detailed  POD  model  of  an  application  to  be 
built.  PCD  allows  the  user  to  specify  program  path  lengths, 
the  number  of  times  a  loop  will  be  executed,  and  flow  of 

control  in  general  as  a  function  of  data  input  frequencies 

$ 

(probabilities)  that  are  meaningful  to  an  end  user.  One 
conclusion  of  this  study  is  that  this  type  of  information 
must  be  included  in  a  system  specification  for  a  detailed 
and  accurate  POD  model  to  be  produced.  Once  this  informa¬ 
tion  is  available,  POD  allows  some  of  the  parameters  to  be 


varied  interactively  to  analyze  how  changes  in  data  input 
frequencies  will  affect  system  performance.  Incorporating 
this  additional  information  in  an  AXES  specification  should 
not  be  particularly  difficult  and  would  be  an  appropriate 
extension  of  the  research  reported  in  the  HOS  report. 

The  complete  specification  of  the  POD  syntax  as  AXES  axioms 
and  conventions  for  embedding  performance  related  informa¬ 
tion  in  an  AXES  requirements  specification  is  left  for  a 
follow  on  task.  Seme  of  the  main  issues  that  could  be  ad¬ 
dressed  there  are: 

1.  shared  domains 

2.  parameter  passing  between  modules  and  module  flow  of 
control 

3.  data  dependence  of  module  performance  and  parameteri¬ 
zation  to  allow  analysis  of  the  effects  of  this  de¬ 
pendence  in  a  way  understandable  to  end  users 

4.  PCD  sources 

5.  incorporating  POD  semantic  relationships  in  the  HOS 
axiom  descriptions. 
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INTRODUCTION 


In  this  report  we  describe  two  related  interfaces  between  Higher 
Order  Software  (HOS)  methodology  and  the  Performance  Oriented  Design 
(POD)  system.  One  interface,  which  is  detailed,  is  the  relation  between 
POD  constructs  and  HOS  mechanisms.  Some  selected  POO  constructs  are 
characterized  in  HOS  terms,  and  then,  from  part  of  an  example  of  a 
system  described  in  terms  of  POD,  a  corresponding  HOS  specification  of 
that  system  is  described.  In  this  way  general  connections  between  the 
two  systems  become  apparent;  for  example,  attributes  in  POD  become 
primitive  operations  on  data  types  in  HOS.  Furthermore,  this  exercise 
suggests  ways  in  which  POD  descriptions  might  be  enhanced  by  using  HOS. 
For  instance,  it  is  seen  that  formal ization  in  terms  of  HOS  makes 
explicit  attributes  that  are  only  implicit  in  POD. 

The  second  interface,  which  is  discussed  more  briefly,  is  the  con¬ 
cept  of  a  POD  Resource  Allocation  Tool  (POD  RAT),  that  is,  a  tool  that 
takes  a  correct  HOS  system  specification  as  input  and  automatically 
generates  a  POD  description.  Since  HOS  specifications  are  guaranteed 
to  possess  certain  crucial  properties  (consistency,  logical 
completeness,  and  interface  correctness,  for  example),  a  POD  RAT, 
which  would  perserve  these  properties,  would  ensure  that  the  resulting 
POD  description  would  also  have  these  properties.  Furthermore,  a 
single  HOS  specification,  after  being  run  through  a  POD  RAT,  could 
equally  well  be  run  through  a  FORTRAN,  PASCAL,  or  other  RAT  for  imple¬ 
mentation,  thereby  doing  away  with  the  need  for  further  coding  of  the 
system. 

Included  in  this  report  is  a  POD  overview,  an  HOS  and  USE. IT 
(FORTRAN/PASCAL  RAT  plus  other  HOS  tools),  overview,  and  a  discussion 
of  these  POD-HOS  interfaces. 
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1.  POO  OVERVIEW 


Performance  Oriented  Design  (POO)  system  is  an  interactive  faci¬ 
lity  that  can  be  used  to  analyze  performance  related  problems  that 
arise  during  the  design,  implementation,  and  evolutionary  development 
of  computer  based  systems.  It  provides  the  following  facilities  to 
the  user: 

•  A  format  (System  Description  File)  for  expressing 
a  system  design's  performance  characteristics 
including  hardware  and  its  interconnections, 
software,  and  workloads  to  be  processed. 

•  A  command  to  read  System  Description  Files  and 
perform  certain  syntax  checks.  (For  example, 
invalid,  redundant,  or  omitted  descriptors  are 
detected. ) 

•  Commands  for  transforming  device  usage  estimates 
from  symbolic  machine-independent  terms  to 
actual  times. 

t  Commands  to  build  and  evaluate  analytic  queueing 
network  models  of  prospective  system  designs. 

•  Commands  to  express  the  model  behavior  in  terms 
of  response  time,  throughput,  device  utilization, 
queue  lengths,  and  other  derived  results. 

•  Commands  to  modify  design  performance  parameters 
interactively  and  evaluate  new  designs  on-line  [I], 

Modeling  of  a  hardware/software  system  can  be  done  on  two  levels 
using  POD.  On  one  level  software  structures  (e.g.  ,  call  structures 


and  resource  requirements)  and  device  capabilities  (e.g. ,  device 
storage  and  processing  capabilities)  are  specified.  In  addition, 
workloads  (a  series  of  jobs  arriving  at  a  computer  system  from  an 
external  source)  and  their  arrival  information  must  be  specified.  On 
another  level,  the  interaction  of  workloads  is  examined.  In  other 
words,  the  contention  for  specific  (hardware)  resources  is  analyzed. 


2. 


HOS  &  USE. IT  OVERVIEW 


Higher  Order  Software  (HOS)  is  a  methodology  for  defining  systems 
in  a  hardware  and  language  independent  manner.  Systems  so  defined 
are  guaranteed  to  be  consistent  and  logically  complete. 

AXES  is  a  specification  language  which  is  based  on  HOS.  It  pro¬ 
vides  the  mechanisms  to  define  functions,  control  structures,  and  data 
types.  A  system  is  viewed  as  a  single  function  which  is  decomposed 
into  successive  levels  of  detail  in  terms  of  other  functions.  Control 
structures  state  the  relationship  between  the  original  function  and 
the  functions  which  make  up  its  decomposition.  There  are  three  primi¬ 
tive  control  structures:  JOIN,  OR  and  INCLUDE,  which  represent  sequen¬ 
tial,  alternative,  and  parallel  processes,  respectively  [2,3]. 

Objects  in  a  system  are  specified  using  data  types.  Data  type 
specifications  provide  the  primitive  operations  that  operate  on  or 
produce  the  objects  of  data  types.  These  operations  are  primitive  in 
that  they  are  not  decomposable,  but  their  implementations  are 
constrained  by  axioms,  i.e. ,  statements  about  the  ways  in  which  they 
can  Interact  with  each  other. 

Abstraction  is  gained  by  defining  additional  mechanisms  using  the 
primitive  mechanisms  or  pre-defined  mechanisms  (and  thus  the 
primitives).  These  mechanisms  are  stored  in  a  library  and  can  be  used 
where  needed. 

The  User  System  Evaluation  and  Integration  Tool  (USE. IT)  is  a 
family  of  tools  by  which  systems  are  defined  (using  AXES),  analyzed 
for  logical  correctness  (using  an  Analyzer),  and  programmed  (using  a 
Resource  Allocation  Tool  (RAT)) [4].  With  USE. IT  a  specification  is 
interactively  constructed  using  AXES  and  checked  by  the  Analyzer  for 
consistency  and  logical  completeness.  The  RAT  then  takes  the  correct 
specification  and  automatically  produces  code. 
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Some  of  the  advantages  of  USE. IT  are  obvious.  Specifications  are 
formulated  in  AXES  and  therefore  analyzable  for  certain  desirable 
properties.  The  Analyzer  ensures  that  AXES  specifications  are  con¬ 
sistent,  free  of  data  and  timing  conflicts,  and  complete.  It  should 
be  emphasized  that  this  is  done  before  implementation.  Since  the  RAT 
automatically  generates  code,  coding  time  is  minimal. 

USE. IT  also  provides  the  user  with  a  library  of  AXES  mechanisms. 
In  this  way  a  user  defines  systems  drawing  upon  mechanisms  found  in 
the  library.  Of  course,  the  user  is  not  limited  to  those  mechanisms, 
but  may  build  his  own  mechanisms  and  store  them  in  a  library  for  use 
whenever  needed. 

The  generality  and  portability  of  USE. IT  allows  it  to  produce 
“code"  in  languages  other  than  the  common  or  traditional  ones.  The 
RAT  currently  produces  FORTRAN  and  PASCAL,  but  a  POD  RAT  is  also 
feasible.  A  POD  RAT  would  take  an  analyzed  AXES  specification  of  a 
system,  and  automatically  generate  a  POD  description  (System 
Description  File)  of  that  system.  This  System  Description  File  would 
then  be  input  to  POD,  which  would  then  produce  the  system's  perfor¬ 
mance  evaluation. 

The  benefit  of  this  approach  is  that  the  definition,  i.e.,  AXES 
specification  of  a  system,  would  have  all  the  desirable  properties 
(consistency,  completeness,  and  correct  data  flow).  USE. IT  would  then 
guarantee  that  the  System  Description  File  it  automatically  generates 
Is  logically  complete.  Moreover,  a  POD  RAT  together  with,  say,  a 
FORTRAN  RAT  would  enable  a  system  to  be  tested  using  POD  and  then 
implemented  in  FORTRAN,  all  from  one  implementation-free  HOS  specifi¬ 
cation.  Conversely,  the  POD  tool  could  be  used  to  help  decide  whether 
the  system  should  be  RATted  into  FORTRAN,  or  whether  some  other 
language  would  be  more  appropriate  for  its  implementation. 
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3.  POO  -  HOS  INTERFACE 


3.1  INTRODUCTION 

HOS/AXES  provides  both  a  language  for  the  definition  of  systems 
and  a  metalanguage  for  the  definition  of  mechanisms  that  can  themselves 
be  used  as  a  language  for  the  definition  of  systems.  In  relation  to  a 
system  like  POD,  the  metalanguage  aspect  emerges  as  primary,  because 
its  own  basic  constructs  can  be  defined  formally  as  HOS  mechanisms, 
thereby  enhancing  POD  with  all  the  benefits  that  that  kind  of  for¬ 
malization  brings.  Furthermore,  a  RAT  that  automatically  generates 
POO  descriptions  from  HOS  specifications  can  be  readily  built  once  the 
semantics  of  POO  is  fully  understood  and  made  explicit. 

3.2  HOS  SPECIFICATION  OF  POD  SEMANTICS 

HOS  characterizes  all  systems  In  terms  of  three  fundamental 
units:  data  types,  functions,  and  control  structures;  and  the  basic 
constructs  of  POO  map  naturally  Into  this  framework.  The  following 
examples  demonstrate  the  manner  In  which  POD  semantics  could  be  for¬ 
malized  with  HOS. 

Oevlces  in  POD,  for  example,  comprise  an  HOS  data  type  [5],  a 
formal  characterization  of  which  is  given  in  Figure  1.  A  user  of  POD 
must  attribute  to  devices  only  those  attributes  which  POD  itself 
attributes  to  them,  either  explicitly  or  implicitly,  and  strict 
adherence  to  the  specification  In  Figure  1  would  guarantee  that  this 
was  the  case.  The  standard  set  of  device  attributes  in  POD  is  given 
in  Figure  2,  and  each  of  these,  as  well  as  the  device  type,  is 
reflected  as  a  primitive  operation  In  Figure  1.  The  default  units  and 
values  in  Figure  2  are  omitted  from  Figure  1  solely  in  order  to 
simplify  the  exposition,  but  they  would  be  included  in  a  more  complete 
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OATA  TYPE:  DEVICE; 

PRIMITIVE  OPERATIONS: 

device  type  »  Device-Type  (device); 

rational  *  Rate  (device); 

list  (of  files)  =  Oevice-map  (device); 

rational  *  Seeks  (device); 

rational  *  Revolution-time  (device); 

natural  *  Capacity  (device); 

string  (of  characters)  »  Operation  (natural .device) ; 

natural  *  Number-of -operations  (device); 

formula  «  Time  (natural,  device); 

natural  *  Multiplicity  (device); 

string  (of  characters)  *  Class  (device); 

AXIOMS: 

WHERE  REJECT  IS  A  MEMBER  OF  EVERY  TYPE; 

WHERE  dev  IS  A  DEVICE; 

WHERE  nat  IS  A  NATURAL; 

Not(0r( Equal (Device-type(dev) ,cpu) , 

Equal (Device-Type(dev) .disk) , 

Equal (Device-Type(dev)  .server))) 

»  Equal (rate(dev), REJECT); 

Not(Or(Equal (Device-type(dev) .defined) , 

Equal (Device-type(dev)  ,defined-cpu))) 

*  Equal (Operation(nat ,dev)  .REJECT) ; 

Equal (Operation(nat, dev), REJECT) 

=  Equal  (Time(nat, dev), REJECT); 

Not(Equal (Device-type(dev) .memory) ) 

a  Equal (Capacity(dev), REJECT); 

Not(Equal (Device-type(dev) .disk) ) 

a  Equal  (Device-map  (dev),  REJECT); 

Not(Equal (Device-type(dev)  .disk) ) 

*  Equal (Seek(dev) .REJECT) ; 

Not(Equal (Device-type(dev) .disk)) 

*  Equal (Revolution-time(dev) .REJECT) ; 

Not(Or(Equal (Device-type(Dev)  ,cpu)  .Equal (Device-type(dev) .disk) )) 
»  Equal (class(dev)  .REJECT) ; 


Not(0r(Equa1 (Device-type(dev) ,cpu) .Equal (Device-type(dev) .server) ) ) 
a  Equal (Multiply(dev) .REJECT) ; 

<(nat,Nu.^ber-of-operation(dev)) 

»  Equal (Operation(nat, dev) .REJECT) ; 


END  DEVICE; 
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Figure  2:  Device  Attributes  in  POD  (from  [1]) 


specification  of  the  data  type.  The  number  of  operations  a  user- 
defined  device  has  is  not  listed  in  Figure  2  as  an  attribute  of  POO 
devices,  but  it  must  be  included  in  the  HOS  specification  in  order  to 
formulate  axioms  that  completely  characterize  the  other  primitive 
operations/attributes.  HOS  formalization  thus  brings  to  light  a 
further  attribute  which  POD  and  its  users  must  implicitly  take  into 
account,  even  though  POD  does  not  explicitly  recognize  it. 

The  effect  of  the  axioms  in  Figure  1  is  to  restrict  each  primi¬ 
tive  operation,  and  thus  each  attribute,  to  exactly  those  device  types 
that  are  appropriate,  by  specifying  that  its  use  rejects  for  devices 
of  other  device  types.  The  first  axiom  states,  for  example,  that  the 
Rate  primitive  operation  rejects  for  a  device  if  and  only  if  its 
device  type  is  not  cpu ,  disk,  or  server,  indicating  that  only  devices 
of  these  three  types  can  properly  be  said  to  have  rates  in  a  POD 
description  of  a  system,  as  figure  2  requires.  The  third  axiom  says 
that  Operation  rejects  if  and  only  if  Time  does  and  so,  together  with 
the  second  axiom,  restricts  both  Operation  and  Time  to  be  applicable 
only  to  devices  of  type  defined  or  defined-cpu.  The  last  axiom  says 
that  the  nth  operation  of  a  (user-defined)  device  exists  if  and  only 
If  n  is  less  than  or  equal  to  the  number  of  operations  for  that 
device.  This  is  necessary  In  order  to  restrict  the  applicability  of 
the  earlier  axioms  that  also  contain  Operation. 

Most  of  the  data  types  that  provide  inputs  or  outputs  to  the  pri¬ 
mitive  operations  in  Figure  1  are  already  available  in  the  general  HOS 
library,  but  one  of  them,  that  of  device  types,  is  entirely  specific 
to  POD  (in  the  present  usage,  at  any  rate).  Since  device  types  are, 
in  fact,  a  kind  of  "object,"  whose  members  get  associated  with  device 
"objects,"  they  must  be  formally  characterized  in  HOS  as  a  data  type, 
just  as  devices  do  themselves.  A  specification  of  the  data  type 
DEVICE  TYPE  is  given  in  Figure  3. 
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DATA  TYPE:  DEVICE  TYPE; 


PRIMITIVE  OPERATIONS: 

I  AXIOMS: 

WHERE  cpu,  disk,  memory,  server,  defined, 
defined-cpu  ARE  CONSTANT  DEVICE  TYPES; 

I  WHERE  dt  IS  A  DEVICE  TYPE; 

WHERE  TRUE,  FALSE  ARE  CONSTANT  BOOLEANS; 

i 

Or (Equal (dt.cpu)  .Equal (dt  .disk)  .Equal (dt .memory) , 
I  Equal (dt, server) .Equal (dt .defined) , 

Equal (dt, defined-cpu ) )  ■  True; 

Equal (cpu.dlsk)  «  False; 

I  Equal (cpu .memory)  *  False; 

Equal (cpu, server)  »  False; 

Equal (cpu .defined)  ■  False; 

Equal (cpu, defined-cpu)  »  False; 

Equal (disk .memory)  *  False; 

Equal (disk, server)  =  False; 

Equal (disk .defined)  ■  False; 

Equal (disk , defined-cpu)  *  False; 

Equal (memory , server)  ■  False; 

Equal (memory .defined)  »  False; 

Equal (memory, defined-cpu)  »  False; 

Equal (server, defined)  *  False; 

Equal (server, defined-cpu)  »  False; 

Equal (defined, defined-cpu)  ■  False; 


END  DEVICE  TYPE; 


Since  device  types  are  used  solely  to  identify  which  attributes 
go  with  which  kinds  of  devices,  and  since  this  has  already  been  spe¬ 
cified  in  Figure  l,  data  type  DEVICE  TYPE  requires  no  primitive  opera¬ 
tions  of  its  own,  and  so  none  are  included  in  Figure  3.  (Equal  Is  a 
universal  primitive  operation,  and  Or  is  a  boolean  one,  both  available 
in  the  HOS  library.)  If  reason  were  found  for  updating  POO  in  some 
way  that  put  device  types  to  further  use,  then  primitive  operations 
and  axioms  that  constrain  them  could  be  added  to  the  data  type  speci¬ 
fication  to  account  for  that.  At  present,  however,  the  data  type  con¬ 
sists  simply  of  six  distinct  members,  identified  in  the  first  WHERE 
statement  as  the  CONSTANT  device  types  cpu,  di sk ,  memory ,  server, 
defined,  and  defined -cpu,  the  device  types  listed  in  Figure  2.  These 
six  device  types  are  characterized  in  relation  to  each  other  in  the 
axioms  in  Figure  3,  the  first  of  which  says  that  any  device  type  at 
all  has  to  be  one  of  the  six,  and  the  rest  of  which  say  that  the  six 
are,  in  fact,  distinct.  Any  further  properties  that  device  types  must 
be  said  to  have  can  be  introduced,  as  necessary,  as  further  primitive 
operations  with  axioms  to  constrain  them. 

An  HOS  specification  of  data  type  FILE  CATALOG  is  given  in  Figure 
4  as  a  further  example.  The  two  essential  components  of  a  file  cata¬ 
log  in  POO  are  file  names  and  record  sizes,  and  these  become  primitive 
operations  on  the  data  type  In  HOS.  The  first  axiom  says  that  the 
length  of  each  file  name  must  be  less  than  or  equal  to  the  value  of 
some  parameter  to  be  specified  by  the  user,  perhaps  in  a  formal  charac 
terizatlon  of  a  data  type  for  file  names.  Length  in  Figure  4  is  a 
primitive  operation  on  strings  available  in  the  HOS  library,  but  it 
could  also  be  specified  more  abstractly  as  a  primitive  operation  on  a 
data  type  FILE  NAME.  The  other  two  axioms  specify  that  record  sizes 
must  fall  within  some  range,  saying  that  they  must  be  greater  than  0 
and  less  than  some  user-supplied  parameter  value.  These  are  sample 
axioms  only.  Further  constraints  are  likely  to  be  necesssary,  espe¬ 
cially  in  connection  with  file  names. 
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DATA  TYPE:  FILE  CATALOG; 


PRIMITIVE  OPERATIONS: 

string(of  characters)  =  Fi le-name(natural ,fi le  catalog); 
natural  =  Record-si ze{natural ,f1 le  catalog); 

AXIOMS: 

WHERE  fc  IS  A  FILE  CATALOG; 

WHERE  nat  IS  A  NATURAL; 

WHERE  0  IS  A  CONSTANT  NATURAL; 

<(tength(F11e-name(nat,fc)),m)  «  True; 
<(0,Record-'size(nat,fc))  =*  True; 

<(Record-s1ze(nat,fc) ,n)  *  True; 

END  FILE  CATALOG; 


Figure  4:  Data  Type  FILE  CATALOG  in  HOS 


Like  devices  and  file  catalogs,  which  comprise  components  of  a 
configuration  specification  in  POO,  workloads  are  also  characterizable 
most  naturally  in  HOS  as  data  types,  as  shown  in  Figure  5.  tike  devi¬ 
ces,  workloads  have  both  attributes,  shown  in  Figure  6,  and  types, 
which  are  themselves  characterizable  as  a  data  type,  as  shown  in 
Figure  7.  Again,  the  attributes  become  primitive  operations  in  HOS, 
with  a  further  primitive  operation  that  assigns  each  workload  its  type. 

The  components  of  POD  module  specifications,  however,  map  Into 
HOS  not  as  data  types,  but  as  control  maps,  i.e.,  structured  func¬ 
tions.  The  loop  in  Figure  8,  for  example,  maps  into  the  function  tree 
in  Figure  9,  in  which  the  data,  subfunctions,  and  structural  relations 
that  are  implicit  in  Figure  3  are  indicated  explicitly.  Notice  that 
the  structure  in  Figure  9  Loop-Number-of-Images-Times ,  is  not  a  primi¬ 
tive  but  a  user  defined  control  structure.  A  formal  specification  of 
this  structure  must  be  provided  to  fully  explicate  the  intended  beha¬ 
vior.  In  a  similar  manner  other  module  sped f icatons  (i.e.  user 
templates)  can  be  fully  specified  in  terms  of  the  true  underlying 
semantics  or  meaning  of  these  usage  oriented  templates.  All  of  the 
POD  modules  must  have  one  of  these  associated  forma!  definitions  asso¬ 
ciated  with  it  if  it  is  to  be  considered  to  be  formally  defined  in  the 
HOS  sense  of  an  AXES  specification.  Following  is  a  walk  through  of 
the  POD  module  as  we  understand  it  (see  Figure  10). 

The  overall  effect  of  the  specification  is  to  define  a  function, 
in  the  mathematical  sense,  called  here  loop-Number-of-Images-Times. 
Choice  of  names  Is  theoretically  arbitrary  in  HOS,  but  good  style 
involves  making  choices  that  enhance  clarity  and  understanding.  This 
function  inputs  values  of  a  variable  alpha  and,  perhaps,  other  input, 
such  as  the  state  of  the  relevant  device.  The  way  the  function  gets 
carried  out  is  indicated  by  the  three  levels  of  decomposition  into 
subfunctions.  First,  a  counter,  n,  is  initialized  to  0  and  then  fed, 
along  with  alpha  and  input,  into  the  function  that  comprises  the  main 
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DATA  TYPE:  WORKLOAD; 


PRIMITIVE  OPERATIONS: 

workload  type  =  Workl  oad-type(workload) ; 
natural  =  Mpl (workload) ; 

1 ist(of(job, percent))  =  Job-stream(workload) ; 
natural  *  Arrival -rate(workload) 
natural  ■  Think-time(workload) ; 
natural  *  Users(workload) ; 

Natural  *  Priority(workload) ; 

AXIOMS: 

WHERE  wl  IS  A  WORKLOAD; 

WHERE  14  IS  A  CONSTANT  NATURAL; 

Equal (Workload-type(wl ) .periodic) 

=  Equal (Mpl (wl), REJECT); 

Equal (Workl oad-type(wl ) .interactive) 

*  Equal  (Job-stream(wl )  .REJECT) ; 
Equal (Workload-type(wl ) .interactive) 

*  Equal (Arrival -rate(we) .REJECT); 
Equal (Workl oad-type(wl ) ,cycl e) 

*  Equal (Arri val -rate(wl ) .REJECT) ; 
Not(Equal (Workload-type(wl ) .interactive) ) 

=  Equal (Think-time(wl ) .RREJECT) ; 
Not(Equal (Workl oad-type(wl ) .interactive)) 

=  Equal (Users(wl), REJECT); 
<(0,Prior1ty(wl ) )  =  True; 

<(Priority(wl )  ,14)  =  True; 

END  WORKLOAD; 


Figure  5:  Data  type  WORKLOAD  in  HOS 
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DATA  TYPE:  WORKLOAD  TYPE; 


PRIMITIVE  OPERATIONS: 

AXIOMS: 

WHERE  cycle,  periodic,  transaction, 
interactive  ARE  CONSTANT  WORKLOAD  TYPES; 

WHERE  wt  IS  A  WORKLOAD  TYPE; 

Or(Equal (wt, cycle) .Equal (wt, periodic) , 

Equal (wt, transaction)  .Equal (wt, interactive) )  =  True 
Equal (cycle, periodic)  =  False; 

Equal (cycle, transaction)  =  False; 

Equal (cycle, interactive)  =  False; 

Equal (periodic, transaction)  =  False; 

Equal (periodic, transaction)  =  False; 

Equal (transaction, interactive)  *  False; 

END  WORKLOAD  TYPE; 


Figure  7:  Data  type  WORKLOAD  TYPE  in  HOS 


LOOP  NUMBER  OF  IMAGES  TIMES 
CALL  TASK  2 (ALPHA) 


alpha',  input'  =  A _USE (alpha, input) 

LOOP-NUMBER-OF- IMAGES-TIMES 
alpha*,  input*  =  TA$K2(alpha .input) 


subfunction,  called  here  Loop-task2.  Kq  is  a  universal  primitive 
operation  of  HOS,  a  function  that  generates  0  as  its  output  value  no 
matter  what  its  inputs  are.  Such  a  constant  function  is  available 
for  use  for  any  member  i  of  any  available  data  type.  Second,  a  func¬ 
tion  called  here  Do-task  updates  alpha,  the  other  input,  and  n  and 
then  determines  whether  to  loop  or  stop,  depending  on  the  currant 
value  of  n,  now  called  n'.  Changing  a  variable's  value  requires  also 
changing  the  variable  itself  in  HOS,  even  if  only  by  adding  a  prime  or 
asterisk,  in  order  to  maintain  traceability  of  data  and  the  possibi¬ 
lity  of  static  checking.  Third,  the  counter  gets  updated  and  Task  2 
actually  gets  carried  out,  after  which,  based  on  the  counter's  value, 
either  loop-task2  gets  recalled  for  that  value  and  the  updated  alpha 
and  input  or  those  values  get  retained  as  the  final  values.  Clonej  is 
another  operation  of  HOS,  one  that  produces  one  copy  of  its  input, 
whatever  that  is,  as  its  output,  i.e.,  makes  possible  a  further 
reference  to  its  input. 


The  symbols  CJ,  0,  I,  and  CO  in  Figure  9  indicate  examples  of  HOS 
control  structures  [2,3],  i.e.,  relations  between  functions  and  their 
subfunctions.  CJ  is  the  COJOIN  structure,  which  indicates  sequential 
execution  and  shared  inputs.  If  n  were  the  only  input  to  Loop-task  2, 
then  the  CJ  could  be  replaced  with  J,  a  purely  sequential  JOIN 
construct,  in  which  the  output  of  one  subfunction  is  the  only  input  to 
the  other.  Such  a  structure  is  involved,  in  fact,  in  the  decom¬ 
position  of  Loop-task  2,  whose  subfunctions  share  no  inputs,  the  out¬ 
put  of  one,  namely,  alpha*,  input*,  and  n' ,  being  the  only  inputs  to 
the  other.  I,  which  decomposes  Do-task2  is  a  parallel  INCLUDE  struc¬ 
ture,  which  partitions  input  and  output  lists  and  matches  the  sublists 
to  each  subfunction  with  no  overlap.  A  COINCLUDE  structure  is  also 
available,  related  to  INCLUDE  much  as  COJOIN  is  related  to  JOIN,  but 
that  structure  is  not  needed  for  this  example.  CO  is  a  C00R  struc¬ 
ture,  indicating  deterministic  alternatives,  which  can  also  be  used  to 
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explicate  the  POO  TEST  construct,  as  shown  in  Figure  11  for  the 
example  ^n  Figure  12.  If  Clone}  (alpha*, input*)  were  replaced  with 
Identify}^  (alpha*,  input*,  n'),  then  this  CQOR  could  be  replaced 
with  an  OR  structure,  which  requires  each  offspring  to  have  exactly 
the  same  inputs  as  the  parent  function.  Identify],...^  ,for  j  <k 
£  i,  is  another  operation  of  HOS,  the  effect  of  which  is  to  extract  the 
jth,...  and  members  of  a  length-i  input  list.  JOIN,  OR,  and 

INCLUDE  comprise  the  three  primitive  control  structures  of  HOS,  out  of 
which  all  other  allowable  structures  can  be  defined.  The  lower-most 
occurrence  of  Loop-task2  re-invokes  the  named  function  for  the  indi¬ 
cated  updated  inputs,  thereby  creating  the  loop  effect  that  is  named, 
but  not  otherwise  represented,  in  the  POD  notation.  If  this  lower 
occurrence  were  replaced  with  some  other  function  name  not  also 
occurring  elsewhere  in  the  tree,  then  this  recursive  effect  would 
disappear. 

It  should  be  stressed  that  Figure  10  gives  an  explicit  account  of 
the  semantics  of  the  syntax  In  Figure  9.  Figure  8  might  seem  easier 
to  use,  and  Indeed  it  i£  easier  to  use  for  one  who  Is  familiar  with 
it,  but  the  fact  that  so  much  of  its  meaning  is  only  Implicit  makes  it 
subject  to  misinterpretation.  Incorrect  usage,  side  effects,  and  so 
on.  The  description  in  Figure  9,  in  contrast.  Is  guaranteed  to  be 
logically  correct,  because  It  has  a  clearly  identifiable  meaning  in 
terms  of  its  formal  definition  in  Figure  10  following  the  HOS  rules, 
which  eliminate  interface  errors  and  ensure  correct  modularization 
[2]. 

3.3  A  RESOURCE  ALLOCATION  TOOL  (RAT)  TO  GENERATE  POD 

If  a  system  is  described  completely  in  HOS  to  begin  with,  POD 
code  can  be  generated  automatically  from  it  with  a  RAT,  as  can  code  in 
any  language  for  which  a  RAT  is  available  [7J.  We  will  use  the 
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output  «  Test-current-mode( input, current  mode) 


Figure  11:  HOS  Control  Map  for  a  POD  CASE  Statement 


Standby( input) 


TEST  CURREMT_KODE 
CASE  'STANDBY' 

CALL  STANDBY 

CASE  'UNDER  ATTACK' 
CALL  DEFENSE 

CASE  'ATTACK' 

CALL  OFFENSE 
EflDTEST 


Figure  1 2:  The  POD  construct  whose  control  map  a 


rs  in 


example  In  the  appendix  (which  just  so  happens  to  be  a  specific  POO 
specification)  to  show  what  it  would  mean  to  specify  it  in  HQS  func¬ 
tional  notation  and  then  show  the  connection  between  that  specifica¬ 
tion  and  a  POO  RAT. 

The  example  in  the  Appendix  consists  of  specific  values  being 
given  to  various  kinds  of  items:  a  file  catalog,  devices,  modules, 
and  so  on;  and  each  such  item  can  be  defined  as  a  CONSTANT  in  HOS  with 
a  WHERE  statement.  An  HOS  specification  of  the  file  catalog  in  the 
example  is  given  in  Figure  13.  For  each  natural  number,  the 
corresponding  file  name  and  record  size  are  specified,  exactly 
reflecting  the  information  contained  in  the  POO  description,  but 
making  more  explicit  the  fact  that  each  of  these  depends  both  on  the 
file  catalog  itself  and  on  a  choice  of  natural  numbers. 

The  first  device  specification  in  the  example  can  be  translated 
into  HOS  as  In  Figure  14,  which  names  the  particular  device  and 
provides  it  with  a  type  and  with  a  value  for  the  attribute  that  is 
required  for  It  by  Figures  1  and  2.  The  other  devices  are  all  disks 
and  have  the  same  values  for  their  Rate  and  Seek  attributes,  so  they 
can  be  specified  either  individually,  as  in  Figure  15,  or,  more 
succinctly,  by  making  use  of  an  HOS  version  of  the  POO  CLASS  construct, 
as  In  Figure  16.  A  specific  workload  can  be  specified  in  terms  of  a 
defined  structure  in  exactly  the  same  way  as  shown  in  Figures  9  and 
10,  for  the  one  in  Figure  17. 

Specific  modules  in  POO  can  be  expressed  in  HOS  as  control  maps. 
The  module  Retrieve-record  in  the  example,  for  instance,  becomes  the 
function  tree  in  Figure  18,  where  the  is  included  only  for 

perspicuity.  As  a  further  example,  the  LOOP  module  DISPLAY  can  be 
written  in  HOS  as  the  control  map  in  Figure  19,  which  has  no  TEST 
construct,  as  Figure  18  does,  but  has  a  recursive  call  to  one  its 
higher  higher-level  functions.  Complete  specifications  of  these 


WHERE  file  catalog  IS  A  CONSTANT  FILE  CATALOG; 

WHERE  FI ,F2 ,F3 ,F4  ,L ,A,D ,SWD ,SUCC  ARE  STRINGS  OF  CHARACTERS; 

WHERE  1.2,3,4,5,6,7,8,9,100,50,36,200,450  ARE  CONSTANT  NATURALS ; 

FI 1e-name(l  ,fi le  catalog)  *  FI; 

FI le-name(2,fi le  catalog)  3  F2; 

Fi 1e-name{3,fi le  catalog)  3  F3; 

Fi 1e-name(4,fi le  catalog)  3  F4; 

File-name(5,fi le  catalog)  3  L; 

File-name(6,fi1e  catalog)  *  A;. 

Fi1e-name(7 ,f1 le  catalog)  3  D; 

File-name(8,fi le  catalog)  3  SWD; 

File-name(9,file  catalog)  =  SWC; 

Record-si ze( 1 , f i le  catalog)  3  100; 

Record-si ze(2,fi le  catalog)  3  100; 

Record-si ze(3, file  catalog)  3  100; 

Record-size(4,file  catalog)  3  100; 

Record-size(5,fi le  catalog)  3  50; 

Record-si ze(6,file  catalog)  3  36; 

Record-si ze(7,fi le  catalog)  3  200; 

Record-size(8,fi le  catalog)  3  450; 

Record-size(9,fi le  catalog)  3  450; 


END  file  catalog; 


WHERE  cpu  IS  A  DEVICE  TYPE; 

WHERE  1.2  IS  A  CONSTANT  RATIONAL; 

WHERE  central  processor  IS  A  CONSTANT  DEVICE; 
Oevlce-type  (central  processor)  =  cpu; 
Rate  (central  processor)  *  1.2; 

END  central  processor; 
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WHERE  20,30  ARE  CONSTANT  NATURALS; 
WHERE  disk  IS  A  DEVICE  TYPE; 

WHERE  disk}  IS  A  CONSTANT  DEVICE ; 
Device-type  (disk^)  =  disk; 
Rate  (diskj)  *  100; 

Seek  (diskj)  =  20; 
Revolution-time  (disk^)  «  30 
Device-map  (diskj)  =  (Fl.SWD); 
END  disk^; 


WHERE  disk2  IS  A  CONSTANT  DEVICE; 
Device-type  (di$k2)  =  disk; 
Rate  (disk2)  *  100; 

Seek  (disk2)  =  20; 
Revolution-time  (disk2)  *  30; 
Device-map  (disk2)  =>  (F2.SWC); 
END  disk2; 

WHERE  disk3  IS  A  CONSTANT  DEVICE; 
Device-type  (di sk3 )  =»  disk; 
Rate  (disk3)  »  100; 

Seek  (disk3)  *  20; 
Revolution-time  (disk3)  =  30; 
Device-map  (disk3)  =  (F3.L.A); 
END  disk3 

WHERE  disk4  IS  A  CONSTANT  DEVICE; 
Device-type  (disk4)  =  disk; 
Rate  (disk4)  »  100; 

Seek  (disk4)  =  20; 
Revolution-time(disk4)  »  30; 
Device-map  (d i sk4 )  =  (F4,D); 
END  di sk4 ; 


Figure  15:  HOS  Specification  of  Some  Specific  Disks 


WHERE  disks  IS  A  CONSTANT  CLASS; 

Rate  (disks)  *  IOO; 

Seek  (disks)  =  20; 

Revolution-time  (disks)  =  30; 

END  disks; 

WHERE  disklt  disk2,  disk3,  disk4  ARE  CONSTANT  DEVICES; 

Device-type  (disk^)  =  disk; 

Device-type  (disk2)  =  disk; 

Device-type  (disk3)  *  disk; 

Device-type  (di sk4)  =  disk; 

Class  (diskj)  =»  disks; 

Class  (disk2)  =  disks; 

Class  (disk3)  «  disks; 

Class  (disk4)  =*  disks; 

Device-map  (d1sk1 )  *  (Fl.SWD); 

Device-map  (di sk2 )  ■  (F2.SWC) ; 

Device-map  (disk3)  »  (F3  L ,A) ; 

Device-map  (d1sk4)  «  (F4,D); 

END  disk^,  disk2,  disk3,  disk4; 


Figure  16:  HOS  Specification  of  the  CLASS  of  Disks  in  Figure  14 


WHERE  5  and  10,000  ARE  CONSTANT  NATURALS; 

WHERE  70%  and  30%  ARE  CONSTANT  PERCENTS; 

WHERE  data  base  usage  IS  A  CONSTANT  WORKLOAD; 

Workload-type  (data  base  usage  )  =  transaction; 

Mpl  (Data  base  usage)  =  5; 

Arrival -rate  (data  base  usage)  *  10,000; 

Job-stream  (data  base  usage)  =  ((Retrieve-record,  70%), 

(Update-record,  30%)), 


END  data  base  usage; 


Figure  17:  HOS  Specification  of  a  Specific  Workload 
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modules  might  require  more  knowledge  about  the  details  of  the  data 
structures  involved  and  perhaps  other  information  as  well  that  is  only 
implicit  in  the  POO  example.  In  contrast  to  the  POD  module  specifica¬ 
tion,  an  AXES  defined  structure  definition  makes  explicit  data,  func¬ 
tions,  control  structures,  and  so  on  that  are  implicit  in  the  POD 
specification's  meaning,  but  not  expressed  in  the  notation.  An  AXES 
specification  has  two  components  in  a  user  defined  structure.  The 
first  is  a  simple  use  oriented  syntax  (as  in  Figure  9)  stating  the 
missing  variable  information  needs  of  the  full  definition  (as  in 
Figure  10).  The  first  is  comparable  to  the  POD  module  specification. 

The  second  is  a  full  system  definition  which  is  hidden  to  simplify  the 
actual  usage  of  that  definition.  This  second  component,  the  defini¬ 
tion  of  the  meaning,  must  be  available  for  a  user  to  really  understand 
what  these  POD  module  specifications  really  do. 

In  general,  performance  information  can  be  derived  from  a  control 
map  in  conjunction  with  information  about  the  hardware  and  resident 
software  (and  so  on)  on  which  it  is  to  be  implemented,  [6j  in  accor¬ 
dance  with  the  general  operation  template 

performance  information  =  P0D-RAT(control  map,  hardware,  resident  software,...), 
(expressed  in  POD  notation)  (all  expressed  in  HOS/AXES) 

For  the  control  map  in  Figure  18,  for  example,  the  INCLUDE  structure 
in  the  lower  right  indicates  the  possibility  of  a  parallel  implemen¬ 
tation.  If  the  hardware  and  resident  software  permit  this  possibility 
to  be  realized,  then  the  structure  can  be  implemented  in  that  way; 
otherwise,  the  two  functions  Access-record  and  Succ  can  be  implemented 
in  sequence,  and  in  either  order,  because  the  possibility  of 
parallelism  implies  non-dependence.  In  either  case,  performance  time, 
say,  of  these  two  primitive  operations  can  be  determined  from  the 
hardware/software  input  and  that  of  Do-access-record  determined  from 
that  and  the  choice  of  implementation  of  the  structure.  Similarly,  the 
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COOR  structure  on  the  lower  left  tells  us  that  only  one  of  the  sub¬ 
functions  is  ever  run  on  a  particular  performance  pass  and  thus  that 
only  one  processor  need  ever  be  made  available  for  executing  the 
structure  as  a  whole,  i.e.,  the  compound  operation  Stop_or_go_on. 

Once  everything  Involved  is  expressed  clearly  in  H0S/AXES--i .e. , 
system  specification,  hardware,  resident  software,  and  so  on--,  all  of 
the  relevant  information  concerning  performance  time,  efficiency, 
etc.,  can  be  readily  determined  by  a  RAT  and  expressed  in  POO  for¬ 
malism  for  processing  as  usual  by  the  POD  tool. 

Rather  than  writing  systems  directly  in  POD,  one  can  write  them 
instead  in  HOS  and  then  generate  the  POD  code  automatically.  The 
advantage  of  this  way  of  doing  things  is  that  the  same  HOS  specifica¬ 
tions  can  also  be  Input  to  other  RATS,  such  as  those  for  FORTRAN, 
PASCAL,  or  other  programming  languages.  Once  a  single  HOS  specifica¬ 
tion  is  completed,  any  number  of  other  versions  of  it  can  be  automati¬ 
cally  generated,  for  any  language  for  which  a  RAT  has  been  built. 
Furthermore,  the  POO  tool  can  be  used  to  evaluate  which  RAT  should 
be  used  to  implement  a  particular  system,  since  RATs  themselves  can  be 
taken  as  Inputs  to  the  POO-RAT  function.  A  system  that  involves  a  lot 
of  concurrency,  for  example,  should  be  RATted  into  an  implementation 
language  that  best  supports  that  facility,  whereas  one  that  has  none 
should  be  RATted  into  a  language  that  does  not,  in  order  to  optimize 
both  resource  usage  and  performance  characteristics.  The  use  of  a  POO 
RAT  in  making  these  decisions  would  optimize  those  decisions,  thereby 
enhancing  system  performance  [6,7]. 

3.4  RECOMMENDATIONS  FOR  FUTURE  WORK 


The  single  most  important  task  that  should  be  undertaken  as  a 
further  development  of  the  HOS-POD  interface  is  the  construction  of  a 
POO  RAT.  Such  a  RAT  would  make  possible  the  automatic  evaluation  of 
systems  expressed  in  H0S/AXE3  in  order  to  determine  their  optimal 
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Implementation  environment  by  generating  POD  descriptions  to  be  input 
to  the  POD  tool.  Writing  systems  in  HOS  would  make  further  coding 
unnecessary,  since  a  single  specification  could  be  used  both  for 
evaluating  and  for  implementing  systems,  as  well  as  for  choosing  the 
optimal  implementation. 

A  second  task  would  be  developing  a  complete  HOS  specification  of 
the  full  POD  semantics,  both  in  order  to  make  explicit  the  full  power 
of  POD  and  also  to  enhance  the  building  of  a  POD  RAT.  A  POD  RAT  could 
be  built  without  such  a  full  specification,  but  its  existence  would 
simplify  and  enhance  the  building  of  a  RAT.  Ideally,  this  task  would 
be  included  as  a  major  subtask  in  the  beginning  stages  of  a  RAT  deve- 
lopment. 
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APPENDIX  a:  demonstrating  pod  functionality 


This  example  involves  the  analysis  of  an  idealized  on-line  system  for 
information  retrieval  and  updating.  Systems  of  thiz  type  are  used  within 
the  Wavy  for  such  purposes  as  maintaining  information  on  the  location  of 
ships i  the  status  of  personnel,  the  availability  of  logistic  support 
facilities,  and  so  on. 

W'e  assume  in  this  particular  example  that  the  information  within  the 
system  is  organized  into  four  files:  FI,  F2,  FJ,  F4.  An  operator  at  a 
terminal  can,  in  a  single  transaction,  either  retrieve  or  change  (update)  a 
record  from  one  of  these  files.  Thus,  the  system  supports  eight  separate 
transaction  types: 

R1  Retrieve  a  record  from  file  FI 

R2  Retrieve  a  record  from  file  F2 

R3  Retrieve  a  record  from  file  F3 

R4  Retrieve  a  record  from  file  F4 

Cl  Change  (update)  a  record  in  file  FI 

C2  Change  (update)  a  record  in  file  F2 

C3  Change  (update)  a  record  in  file  F3 

C4  .  Change  (update)  a  record  in  file  F4 

In  transaction  types  R1  -  R4,  the  operator  types  in  a  record 
identifier  (a  key),  and  the  system  retrieves  the  appropriate  record  and 
displays  its  contents  on  a  screen.  Thus,  files  FI  -  F4  function  as  indexed 
files. 

In  order  to  process  a  transaction,  it  is  necessary  to  swap  the 
appropriate  processing  routines  into  main  memory,  access  one  of  the  four 
data  files  (FI  -  F4),  and  also  access  a  log  file  (L),  an  accounting  file 
(A)  and  a  display  file  (D).  The  average  number  of  accesses  per  transaction 
to  each  of  the  files  is  given  below: 
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File  accesses/transactior. 

Note  that  there  are  two  swap  files:  the  data  swap  file,  SVD,  and  the 
code  swap  file,  SWC .  Upon  initiation  of  a  transaction  both  data  (from  SVD) 
and  code  (from  SWC)  are  swapped  in.  Upon  termination  of  a  transaction  only 

the  data  ia  swapped  out  (to  SVD}  since  the  code  is  pure.  Thus  each 

transaction  accesses  SWD  twice  and  fVC  once. 

In  the  case  of  the  "retrieve"  transactions  -  R4) ,  the  two  accesses 

to  the  data  files  (FI  -  F4)  represent  one  access  to  the  index  and  one 

access  to  the  data  itself.  Ir.  the  case  of  "change"  transactions  (Cl  -  C4) , 
the  system  is  designed  so  that  a  change  must  always  follow  a  retrieve  and 
will  always  alter  the  record  that  has  jus't  been  retrieved.  Thus,  the 
access  to  the  index  is  eliminated.  However,  it  is  necessary  ia  this  case 
to  carry  out  a  second  read  access  after  the  record  has  been  written  tc 
verify  the  fact  that  there  were  no  errors  m  the  write  operation.  The 
value  that  is  actually  read  from  the  disk  after  writing  is  displayed  on  the 
screen  as  part  of  the  "change"  transaction. 

Performance  Data 

Assume  that  the  system  being  evaluated  has  four  high  speed  disk 
drives,  each  with  a  transfer  rate  of  100  bytes,  msec,  ar.  average  seek  time 
of  20  msec  and  a  revolution  time  of  70  msec.  Also  suppose  that  the  files, 
are  mapped  onto  the  disks  as  follows: 

DISK  1:  FI ,  SVD 

DISK  2:  F2,  SWC 

DISK  3s  F3,  L,  A 

DISK  4:  F4,  D 


Assuae  that  the  following  information  is  also  known: 

Transaction  arrival  rat *  ■  tOOOO  per  hour 
Retrieval  percentage  ■  70$ 

(HI  -  R4  all  occur  in  equal  proportions) 

Change  percentage  *  30$ 

(Cl  -  C4  all  occur  in  equal  proportions) 

Number  of  message  regions  a  5 

Initial  POD  Specification 

The  facilities  of  POD  will  co  demonstrated  by  addressing  -he  following 
questions : 


1 .  Someone  has  suggested  that  it  might  be  possible  to  improve 
average  data  base  transaction  response  time  by  maxing  the  index 
portions  of  files  FI  -  ?4  memory  resident.  Thi3  would  save  one 
disk  access  in  transaction  types  R1  -  R4.  In  addition,  by 
eliminating  the  CPU  overhead  necessary  to  initiate  the  index 
access  (and  carrying  out  other  optimization  steps  while 
modifying  the  code),  assume  it  is  possible  to  reduce  the  average 
CPU  time  required  for  the  module  accessing  the  index  by  90$. 
Assume  also  that  it  is  necessary  to  reduce  number  of  message 
regions  by  two  in  order  to  make  the  index  portions  of  the  files 
memory  resident.  How  will  this  suggestion  affect  overall 
response  time? 

2.  Assume  that  the  load  on  the  system  is  expected  to  grow  to  14350 
transactions  per  hour  in  the  next  year.  What  will  the  response 
time  be  at  that  time  for  both  the  memory  resident  and  the  disk 
resident  options? 

3-  Assume  that  a  faster  CPU  will  be  available  when  the  14350 
transaction  per  hour  load  is  reached.  The  faster  CPU  will 
execute  instructions  in  an  average  of  10$  faster  than  the 
current  CPU.  What  will  the  response  times  be  for  each  option  if 
the  faster  CPU  is  used? 


The  following  is  a  sample  POD  System  Description  File  that  contains 
sufficient  detail  to  address  these  issues.  It  should  be  noted  that 
liberties  have  been  taken  in  selecting  the  CPU  processing  requirements  of 
the  modules  and  the  file  organization  characteristics.  In  general,  such 
data  would  have  to  be  collected  and  supplied  by  the  user. 
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global. declaration 
PARAMETER 

PILE  REQUEST  -  ’?! ’  25$ 


END 

END 


CONFIGURATION. SPECIFICATION 
FILE  CATALOG 

NAME- FI .  RECORD  3IZ2-100 
NAME-F2,  RECORD'S!  ZE- ICO 
NAME-F3,  RECORD"SIZE-1CO 
NAME-F4,  REC0RD“SIZ£*100 
NAME-L,  RECORD  SIZE-50 
NAME- A,  RECORD"" SIZE-36 
NAME-D,  RECORD-” SIZE-200 
NAME-SVD,  RECORD  SIZE -4 50 
NAME -SVC ,  RECORD  SIZE-450 
END  ~ 


DEVICE  CENTRAL_?ROCESSOR  TYPE  »  CPU 
RATE  -1.2  SKIP 
END 


DEVICE  DISKI  TYPE  -  DISK 
RATE  »  100  &KSYTES/SEC 
SEEK  -  20  acMSEC 
REVOLUTION  TIME  -  30  SMS2C 
DEVICE  MAP-" *  FI  ,  SVD 

END 

DEVICE  DISK2  TYPE  -  DISK 
RATE  -  100  &KBYTES/SEC 
SEEK  -  20  &MSEC 
REV 0LUTI0N_TIKE  -  30  &MSEC 
DEVICE  MAP  -  F2,  SVC 

END 

DEVICE  DISK3  TYPE  *  DISK 
RATE  -  100  4K3YTES/SEC 
SEEK  -  20  «MSEC 
REVOLUTION  TIME  -  30  iMSEC 
DEVICE  MAP- -  F'5.  L.  A 

END 

DEVICE  DISK4  TYPE  -  DISK 
RATE  -  100  4K3YTBS/SEC 
SEEK  -  20  AKSEC 
REVOLUTION  TIME  -  30  AMSEC 
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DEVICE  MAP  •  7i, 


END 


a..: 


WORKLvAD. SPECIFICATION 

WORKLOAD  DATA  BASE  USAGE  TYPE  *  TRANSACTION 

vrcT  m  x 
•**  ^  / 

ARRIVAL  SATE  «  iCOOC  i/KS 
JOB  STSiAM  «  RETRIEVE  SEC CRT  '*2 
UPDATE  RECORD  ;C  0 


END 


END 


MODULE . SPECIFICATION 
i RETRIEVE  A  DATA  BASE  RECORD: 

MODULE  RETRIEVE  RECORD 

EST  CENTRAL"P?.OCESSCR  USAGE  -  ll-O:  ZY.Z 
CALL  SWAP  IN'" 

TEST  PILE_REQUEST 

case  Tr 

CALL  ACCESS  INDEXCFI’) 

CALL  ACCESS*” RECORDS  *  FI  *  ) 

CASE  '12' 

CALL  ACCESS  INDEX(*F2*) 

CALL  ACCESS  JtECORD(  '12') 

CASE  ’FT 

CALL  ACCESS  INDEX  (' ?V 
CALL  ACCESS*" RECORD  (Ty' 

CASE  ' ?4 ’ 

CALL  ACCESS__INDEX(  '  F4 ' ) 

CALL  ACCESS_RECGRD( 1 F4  * ) 

SNDTEST 
CALL  DISPLAY 
CALL  CLEANUP 
CALL  SWAP  OUT 


AUPDATE  A  DATA  BASE  RECORD: 

MODULE  UPDATE_RECORD 

EST  CENTRAL  PROCESSOR  USAGE  -  50400  INS 
CALL  SVAP_IN~ 

TEST  ?ILE_REQUEST 
CASE  ’?1 * 

CALL  WRITE  RECORDt * ?1 ’ 5 
CALL  VERIFY  VRITE( ' l1 1 ) 

CASE  '12' 

CALL  WRITS_RECGRD( *  ?2  * ) 

CALL  VERIFYJWRITE(  *  F2  ’ ' 

CASE  'IV 

CALL  WRITE  RSCORDC?”') 

CALL  VERIFY  WRITE ( ‘  ‘ ' 

CASE  ' F4 ' 

CALL  WRITS  RECCRD( ' ?4* ' 
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CALL  VERITY  WRITER  '  T4  ‘ 
ENDTEST 
CALL  DISPLAY 
CALL  CLEANUP 
CALL  SWA?  CUT 


&  AC  CESS  A  RECORD  FROM  THE  SPECIEIZT  ■ 
MODULE  ACCESS  RECQEDv FILE' 

EST  CENTRAL  PROCESSOR  USAGE  - 
TEST  PILE  "* 

CASE  ’?1 • 

EST  FI  USAGE  «  1  READ 
CASE  * F2 ’ 

EST  F2  USAGE  -  1  REAL 
CASE  *F3 ’ 

EST  F3  USAGE  -  1  READ 
CASE  *F4* 

EST  F4  USAGE  -  1  READ 
CASE  *D‘ 

EST  D  USAGE  *  1  READ 
ENDTEST 

END 


* -2 DC  INS 


4ACCES5  THE  INDEX  ON  THE  SPECIFIED  FILE: 

MODULE  ACCESS_INDEX ( FILE ) 

EST  CENTRAL_PROCESSOR  USAGE  -  90480  INS 
TEST  FILE 
CASE  ‘FI  * 

EST  FI  USAGE  •  1  READ 
CASE  *F2‘ 

EST  ?2  USAGE  -  1  READ 
CASE  ‘73’ 

EST  F3  USAGE  •  1  READ 
CASE  ‘F4‘ 

EST  ?4  USAGE  -  1  READ 
ENDTEST 
END 

ADI SPLAY  THE  RETRIEVED  RECORD: 

MODULE  DISPLAY 

EST  CENTRAL  PROCESSOR  USAGE  -  16800  INS 
LOOP  2  TIMES"" 

CALL  ACCSSS_RECORD( ’ D ’ ) 

END LOOP 
END 


A INFORM  THE  LOG  ANT  ACCOUNTING  FILL. 
MODULE  CLEANUP 

EST  CENT?.AL_?ROCESSC=  USAGE  ■ 

<»  •  •  *  V T?  “*'?  *  »  •  ' 

■  4 1  *  *  W  ♦  '  .  .  v  ^ 

%  7.- 


Or  THE  TRANSA 
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END 


A WRITS  A  RECORD  TO  THE  C?Er.  .  lit?.?  ■:.? 

MODULE  WHITE  RECCRDIFILF 

EST  CEHTSaL_?P.CCESScR  USAGE  -  2:  'CO  i:::; 

TEST  FILE 
CASE  'FI ' 


EST  ?!  USAGE  =  •  which 
CASS  '72* 

EST  72  USAGE  ■  !  -SITE 
CASE  '?y 

EST  77  USAGE  =  1  WHITE 
CASE  '70' 


EST  74  USAGE  =  1  WE  ITT 

1  »  t  ‘ 

w  £4  A 

EST  A  USAGE  =  *  WHITE 
CASE  *L' 

EST  L  USAGE  =>  :  '..HITE 

ENDTEST 

END 


<5 VERIFY  THAT  THE  CHANGE  TO  THE  FILE  12  CC ERECT 
MODULE  VERI?Y_VRITE( FILE ) 

EST  CENTRAL  PROCESSOR  USAGE  -  29800  INS 
TEST  FILE 
CASE  'FI ' 

EST  FI  USAGE  -  1  READ 
CASE  'F2‘ 

EST  ?2  USAGE  *  1  READ 
CASE  '?y 

•  EST  ?3  USAGE  »  1  READ 
CASE  'F4 ' 

EST  F4  USAGE  -  1  READ 
ENDTEST 
END 


ASVAP  IN  THE  REQUIRED  DATA  AND  CODE 
MODULE  SVAP_IN 

EST  CENTRAL__?ROCESSOR  USAGE  -  27900  INS 
EST  SWD  USAGE  -  1  READ 
EST  SVC  USAGE  -  1  READ 


A SWAP  OUT  THE  DATA 
MODULE  SWAP  OUT 

EST  CENTRAL  PROCESSOR  USAGE  =  2 7900  INS 
EST  SVD  USAGE  -  1  WRITE 
END 


END 
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The  POD  System  Description  File  represents  the  basic  spec  if ication  of 
the  system  wi*h  the  disk  resident  indices.  Specifically,  the  Global 
Declaration  Section  defines  FILE_REQUEST  to  account  for  the  variability  in 
an  arriving  transaction’s  request  to  one  of  the  files  FI  -  F4.  The 
Configuration  Specification  Section  describes  the  organisation  of  all  of 
the  files,  the  mapping  of  the  files  to  the  disks,  and  the  characteristics 
of  the  hardware.  The  Workload  Specification  Section  defines  a  single 
workload,  DATA_BASE  USAGE,  which  has  a  load  of  10,000  requests/hour  of 
which  70%  invoke  module  RETRI2VE__RECQRD  and  30%  invoke  module 
UPDATE  RECORD.  This  represents  transactions  R1-R4  and  C1-C4  respectively. 
The  MPL  parameter  constrains  the  number  of  transactions  the  system 
processes  in  parallel.  The  Module  Specification  Section  represents  the 
system  software.  The  function  of  each  module  in  described  through  the 
comments  in  the  System  Description  File. 

Note,  the  above  System  Description  File  portrays  th*»  system  with  the 
disk  resident  index  option  only.  In  order  to  portray  the  system  with  tne 
memory  resident  indices,  two  changes  to  the  System  Description  File  are 
required.  First  the  workload  specifications  must  indicate  the  reduced 
number  of  message  regions.  Second,  the  ACCESS_INDEX  module  need  not 
reference  files  F1-F4  for  the  indices  and  incurs  a  savings  of  90?  in  its 
CPU  processing  requirement.  These  changes  are  depicted  below. 


Modified  Workload  Specification  Section: 


WORKLOAD. SPECIFICATION 


WORKLOAD  DATA__3A3E_USAGE  TYPE  »  TRANSACT 
MPL  *  ; 


ARRIVA1JUTZ 
JOE  STREAM  • 


ia»D 


-  10000  &/HR 
RET?.ISVS_RECORD  70 % 
UPDATE  RECORD  30? 


ON 


END 


% 
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Modified  ACCESS_INDEX  Module: 

MODULE  ACCESS  INDEX 

EST  CENTRAL  PROCESSOR  USACE  -  ?048  INS 
END 

Also ,  CALLs  to  the  module  ACCESS_INDEX  wer?  changed  to  remove  the 
passed  parameter  since  the  parameter  is  no  longer  required. 

Note,  in  order  to  distinguish  between  these  two  System  Description 
Files  in  the  remainder  of  this  discussion,  we  refer  to  the  file 
representing  the  disk  resident  option  and  the  memory  resident  option  by 
file  numbers  46  and  47  respectively.  We  are  now  in  a  position  to  invoke 
the  interactive  facilities  of  POD  to  investigate  the  issues  cited  above. 

The  interactive  session  first  investigates  the  performance  of  the  system 
with  the  disk  resident  index  option  nnd  next  with  the  memory  resident  index 
option. 
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The  data  produced  from  this  POE  interactive  session  is  summarized  in  Figure 
A-1  . 


ENVIRONMENT 

LOAD 
(per  hr) 

;  tVirAac. 

RESPONSE  TIME 
(per  sec) 

CPU 

UTILIZATION 

DISK  RESIDENT  INDEXES 

10,000 

1.16 

64.6 

MEMORY  RESIDENT  INDEXES 

10,000  . 

1.01 

51  .4 

DISK  RESIDENT  INDEXES 

14,350 

26.04 

92.7 

MEMORY  RESIDENT  INDEXES 

14,350 

20.  CO 

73.8 

DISK  RESIDENT  INOEXES 

PLUS  CPU  UPGRADE 

14,350 

3.26 

84.3 

MEMORY  RESIDENT  INDEXES 

PLUS  CPU  UPGRADE 

14,350 

4.14 

57.1 

Figure  A-*  :  Summary  nf  hf-sui  ts 


The  results  3how: 


o  The  system  using  disk  resident  indexes,  while  producing 

acceptable  levels  of  response  currently,  will  be  incapable  of 
processing  the  expected  future  load  with  acceptable  response 
delay. 

o  Slight  reduction  in  response  time  is  achieved  by  using  memory 
resident  indexes  over  the  disk  resident  indexes  in  the  current 
time  frame.  With  the  heavier  workload  anticipated  ir.  the  future 
time  frame,  the  reverse  ran  h°  expected. 

0  In  the  future  time  frame  response  time  will  be  unacceptable 

unless  ere  faster  CPU  vr  obtained,  regardl-ss  of  tr.e  index  option 
selected . 
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